Infraforage

From Ingress To Gateway API

October 30, 2025 by Abhishek Jha

Ingress-GWAPI


Many clusters still rely on the classic kubernetes Ingress, while the Gateway API is becoming the new norm. This blog will talk abount when and how to move, with concrete, operator and app-team perspective.

Target Audience:
1. Platform Engineers.
2. App Team Leads.

I will try to answer these questions:

1. Do you really need to migrate ?
2. Vendor Options Supporting the Kubernetes Gateway API.
3. A low-risk, gradual migration strategy.

Ingress:
  1. Simple, Layer 7 ( Application Layer) supports only HTTP and HTTPS.
  2. You will deal with only two types of resources :
    1. IngressClass (The controller).
    2. Ingress (The routing rules).
  3. Widely used and supported.
  4. Custom annotations for declarative controller enhancement.
  5. Legacy and forzen.
If your workload is small, and your organization values simplicity, maturity, and a low operational overhead over the advanced features offered by the Gateway API, do not migrate !

Gateway API:

If you need to leverage advanced routing capabilities, such as:
  1. Role separation (GatewayClass)
  2. Robust, Layer 4 & 7, supports HTTP, HTTPS, TCP, UDP, gRPC.
  3. Built in cross-namespace support.
  4. Strong Multi-trnancy. Different team or namespace can define routes differently.
  5. Actively being developed and furture standard.
Vendor Options Supporting the Kubernetes Gateway API.
  1. Open Source and Community Projects - NGINX Gateway Fabric, Envoy Gateway HAProxy, Traefik, Contour, Istio, APISIX, etc..
  2. Cloud Provider - EKS, GKE, AKS, etc..
  3. Enterprise and API Management Platforms - Kong Gateway, Gloo Gateway (by Solo.io), Tyk, etc..
I already had NGINX Ingress set up for one of my applications running on EKS. Route 53 was handling the internet traffic and routing it to the ALB created by the Ingress. For the Gateway API controller, I decided to go with Envoy Gateway. After that, I needed to convert my existing Ingress rules into Gateway API resources.
Ingress2gateway is a prefect tool to do this.
Once that was done, the Gateway API spun up a new ALB, which I then added as a CNAME record in Route 53. To make the migration safer, I decided to create a parallel infrastructure so I could test things using a canary strategy and shift traffic gradually. This setup gave me the flexibility to roll back instantly if anything didn’t go as planned. I used weighted routing in Route 53 to distribute traffic between the old and new environments.
Running a parallel setup does add some temporary cost, but it’s worth it — especially for production or business-critical applications where rollback speed is more important than saving a few dollars. Once the new stack proved stable, I could easily retire the old infrastructure and continue with the new Gateway API–based setup.
Migrating from NGINX Ingress to the Gateway API turned out to be a great opportunity to modernize my traffic management setup on EKS. With Envoy Gateway as the controller, I was able to simplify configuration, gain more flexibility in routing, and align with the future of Kubernetes networking.
Setting up a parallel infrastructure with canary-based DNS routing through Route 53 made the transition seamless and safe, without any downtime. It also gave me the confidence to roll out gradually, observe real-world traffic behavior, and roll back instantly if needed.

If you’re planning a similar migration, I’d recommend:
  1. Start with a small, non-critical application to get familiar with Gateway API resources.
  2. Use weighted routing for a controlled traffic shift.
  3. Keep your rollback path ready until full cutover.
You can find the architecture diagram and implementation code in my GitHub repository for reference. Overall, the migration was smooth, future-proof, and a step toward a more scalable and standardized way of managing Kubernetes networking.